Troubleshooting: Summary Of Troubleshooting Methods For Taiwan Server Ip Cloud Host Connectivity Anomalies

question 1: how to quickly determine whether it is a network link problem or a connectivity abnormality caused by the configuration of the server itself?

the first step in troubleshooting is to quickly distinguish link problems from host problems. prioritize the investigation from the outside to the inside layer by layer: first confirm whether the public network routing and icmp are accessible, and then check the cloud host operating system and application layer.

diagnosis ideas

conduct a simple connectivity test on the target taiwan server ip from the external network; if the external network is unreachable, conduct an intranet mutual test from the cloud platform console or another cloud host to determine whether the blockage is caused by the host or security group.

specific steps

1) execute at the local or third-party monitoring point: ping ip , traceroute (or tracert), record packet loss/hop abnormality; 2) log in to the cloud platform console, use the "console terminal" or the platform's own network diagnostic tool to test from the same availability zone; 3) if the console is reachable but the external network is not reachable, focus on checking the routing/public network exit and asn operator issues; 4) if the console is also unreachable, check the cloud host system network services (network card, default gateway, network segment) and firewall.

things to note

when troubleshooting, be sure to save the output of each step (time, node, packet loss rate) for use when communicating with idc/cloud vendor support.

question 2: what are the commonly used troubleshooting commands and tools, and what scenarios are they suitable for?

proficient use of tools can significantly shorten the time for troubleshooting connectivity anomalies . tools can be divided into three categories: link layer, transport layer and application layer.

diagnosis ideas

first do link layer detection (ping/traceroute), then do port detection (telnet/nc/nmap), and finally do service layer detection (curl/browser/log).

specific steps and tools

1) ping: detect icmp connectivity and delay; 2) traceroute/tracert: locate routing hops and packet loss nodes; 3) mtr: display packet loss and delay changes in real time; 4) telnet ip port or nc -vz: check whether the tcp port is reachable; 5) nmap: scan ports and services; 6) curl/wget: detect http/https application layer response; 7) tcpdump/wireshark: capture packets and analyze tcp three-way handshake, rst, icmp unreachable and other messages; 8) cloud provider built-in diagnosis (such as alibaba cloud, tencent cloud, aws network diagnostic tools).

things to note

packet capture needs to be performed when a problem occurs, otherwise key packets may not be obtained. be careful to follow compliance and security policies when using these tools to avoid unauthorized scanning of external hosts.

question 3: how to locate routing and link problems when cross-border access to taiwan cloud hosts encounters large delays or packet loss?

cross-border links are easily affected by operator bgp, submarine cable paths, pop points, etc. when positioning, multiple measurement points and bgp information must be combined to determine.

diagnosis ideas

by comparing hop differences through traceroute in multiple locations, combined with bgp routing, you can find out whether there are unreasonable detours or black holes; at the same time, pay attention to whether there is a large number of packet losses or high delays in a certain hop.

specific steps

1) perform traceroute/mtr on the target taiwan server ip from different regions (local, hong kong, and multiple idcs in mainland china) at the same time to collect delay and packet loss conditions; 2) use bgp looking glass or online routing query (such as bgp.he.net) to view the target asn and path; 3) if a certain operator node is found to have high packet loss, record the hop ip and consult the operator or submit a cloud vendor work order; 4) if there is a submarine cable or cross-border link problem, prepare the routing table, traceroute output, and time period information to issue a work order. if necessary, ask the cloud vendor or operator to perform traffic optimization or switch exits.

things to note

cross-border fluctuations may be time-sensitive, so it is best to collect multiple pieces of data at different time points to avoid one-time misjudgment.

question 4: the cloud host port is blocked or access fails. how to check the security group, acl and host firewall settings?

the network security policy of the cloud platform (security group, acl, cloud firewall) and the firewall in the host (iptables, firewalld, ufw) may cause abnormal cloud host connectivity .

diagnosis ideas

first check the cloud platform security group and network acl, then check the firewall and application listening port in the host, and finally verify whether there is a nat or port forwarding rule conflict.

specific steps

1) log in to the cloud platform console, check the security group rules and subnet acl bound to the target cloud host, and confirm whether the inbound/outbound port and ip whitelist are allowed; 2) execute ss -tunlp or netstat -tunlp on the cloud host to confirm whether the application is listening on the desired port; 3) check the host firewall status (systemctl status firewalld / ufw status / iptables -l), temporarily close the firewall to verify connectivity (test on the intranet if there is a risk); 4) if using public ip and elastic ip, confirm that the elastic ip is correctly bound and the cloud vendor's snat/dnat rules are not misconfigured; 5) use tcpdump to capture the inbound/outbound packets of the target port and determine whether they are discarded or responded to by rst.

things to note

before modifying security groups or firewall rules, back up the configuration and schedule maintenance to avoid misoperations that may cause greater impact.

question 5: the cloud host ip suddenly becomes unreachable. how to communicate with the cloud vendor or operator and provide effective diagnostic information?

when communicating with cloud vendors/operators, you need to provide clear, reproducible evidence with a timeline, which can speed up troubleshooting.

diagnosis ideas

retrieve and organize the raw data of connectivity tests (ping, traceroute, mtr, tcpdump) and cloud platform logs (console events, audit logs, bgp alarms, etc.).

specific steps

1) collect ping/traceroute/mtr output within the time window and mark the start and end time of the problem; 2) provide cloud host related configuration screenshots or text (instance id, elastic ip, subnet, security group, routing table, nat gateway); 3) upload host-side packet capture (tcpdump) or system log (/var/log/messages, application log), and explain whether it can be accessed from the console; 4) if you suspect a bgp or operator link problem, provide the hop ip and asn information of the traceroute transfer problem; 5) clarify expectations in the work order (such as restoring connectivity/route optimization/troubleshooting packet loss nodes) and attach contact information and communication time.

things to note

after submitting a work order, keep communication channels open, respond promptly to additional information requested by the manufacturer, and request support engineers to conduct end-to-end joint inspections when necessary.